隨著鐵人賽進入尾聲，我們的雲端架構已經具備了相當現代化的水準，前幾天我們用條件式存取、單一登入 (SSO) 以及 App Proxy，把公會的靜態防禦大門鎖得死死的。
但在真實的資安戰場中，暗影神偷總有辦法透過釣魚信件騙走村民的密碼，甚至直接到黑市買到外流的憑證，當壞人拿著「完全正確的鑰匙」光明正大來開門時，單靠靜態結界是不夠的。
這時候我們就要導入公會的 AI 警報雷達：Microsoft Entra ID Protection (身分識別保護)，它會利用微軟在全球佈下的海量威脅情報網(Threat Intelligence)，在使用者嘗試登入的「當下」，即時算出這筆登入行為到底有多危險。

• 兩種風險維度的威脅偵測
  在 ID Protection 的雷達圖裡，風險被精準拆分成兩個不同的維度：

1. 登入風險：針對「這一次」的行為
   • 情境：雷達發現這個帳號正在透過匿名的 IP（例如 Tor 洋蔥路由）、從來沒見過的陌生位置，或是被微軟情報網標記為「惡意軟體連線」的 IP 嘗試登入。
   • 判斷：使用者的帳號可能還沒完全被盜，但當下的這筆連線極度可疑，很可能是駭客正在嘗試攻擊。
2. 使用者風險：針對「這個人」本身
   • 情境：雷達發現這個帳號的密碼，昨天早就被暗影神偷公佈在暗網 (Dark Web) 上販售了；或是系統抓到了「非典型旅行 (Atypical travel)」——這位村民十分鐘前才在台灣的弓箭手村登入，現在卻突然「瞬移」到倫敦登入。
   • 判斷：這代表這個帳號本身大概率已經淪陷、被壞人完全掌握了，必須立刻採取強制措施（例如強制重設密碼或阻斷連線）。

實作

為了徹底落實最小權限原則，最理想的做法是：平時不打擾員工，但當系統偵測到中度以上的登入風險時，不直接封鎖而是強制要求再次驗證MFA！

1. 啟用「登入風險」自動化防禦
   a. 進入到保護裡面的風險條件式存取，新增原則。
   
   b. 輸入名稱：Require MFA for Risky Sign-ins
   c. 指派使用者：測試帳號 Cloud.User1(千萬不要選「所有使用者」，避免把自己鎖死！)
   
   d. 目標資源：所有雲端應用程式
   
   e. 條件：登入風險
   • 設定：是
   • 選取此原則將套用的登入風險層級：高、中
     
     f. 授權
   • 授與存取權：需要多重要素驗證
     

完成這個設定後，當異常IP嘗試登入時，暗影神偷即便拿到密碼，也會因為觸發了中度風險而被微軟制要求輸入 MFA。